1. Field of the Invention
The invention relates to circuit simulators and in particular to a system for processing simulator output data representing behavior of a simulated circuit's individual signals to produce descriptions of transactions occurring on a bus conveying those signals.
2. Description of Related Art
Hierarchical IC Designs
An IC designer typically generates a hardware description language (HDL) netlist describing an IC in terms of the logical relationships between the various signals conveyed by networks (“nets”) within the IC. The designer then uses a synthesis tool to convert the HDL level netlist into a gate level netlist describing the IC as an interconnected set of standard logic gates and other IC components (“cells”) that are to implement the logic described by the HDL netlist. The designer then uses placement and routing tools to generate an IC layout specifying a position of each cell within the IC and specifying how the nets are to be routed between the cells' terminals.
A hierarchical netlist organizes an IC's cells into low level modules and organizes low-level modules into larger, progressively higher-level modules. For example, a collection of interconnected gate cells might form a counter module, the counter module may form a part of a higher-level arithmetic logic unit (ALU) module, and the ALU module may form a part of a higher-level central processing unit (CPU) module. At the highest level of the design hierarchy, an IC may include several large modules such as memories, peripheral device controllers, and the like that communicate with the CPU. The hierarchical nature of the netlist makes it easier for a designer to comprehend an IC design, because it is easier for him or her to think of an IC as being a set of high-level modules, each having a clearly recognizable high-level function, than as merely a collection of interconnected low-level cells.
Buses and Bus Transactions
The cells at the lowest level of the design hierarchy communicate with one another through individual signals conveyed on nets interconnecting the cells' input and output terminals. But designers often think of modules at higher levels of the design hierarchy as communicating with one another though buses. A bus is a set of nets conveying a collection of interrelated signals working together to convey information. For example, a conventional computer bus might include several nets for conveying separate bits of a data, address and control data words and a clock signal. The control signals may indicate, for example, whether the data is to be read out of or written to the address. Clock signal edges indicate when the other signals are at valid logic levels. Designers call the process of transfer data between modules via a bus a “bus transaction”. Thus a bus can be viewed as the individual nets (“bus lines”) needed to convey all of the signals the modules need for carrying out a set of bus transactions between the modules.
Depending on the nature of the bus transactions carried out over a bus, the number of lines the bus may require can range from as little as one to several dozen or more. When the only transaction to be carried out is to convey the state of a single bit, the bus may need only a single data signal line. However, if the data signal is to be sampled by a receiving module at particular times, the bus may also require a clock signal line for controlling sampling. A simple parallel computer bus allowing a central processing unit (CPU) to read and write access storage locations in a random access memory might include, for example, 16 data lines, 16 address lines, a set of control lines and a clock line. Many types of transactions can occur on a bus and with each type of transaction involving a characteristic signaling protocol.
Simulation
At each step of the design process, the IC designer will normally employ various tools to verify that the IC (or some selected portion of it) described by the netlist will behave as expected. For example, a computer-based circuit simulator simulates the behavior of an IC described by a netlist in response to a set of input signals and generates a “dump file” containing waveform data sequences describing how the IC's input, output and internal signals behave. The waveform data sequence for each signal indicates the state of the signal at a succession of times relative to edges of a clock signal controlling the timing of state changes in that signal. Conventional waveform display software can then process the waveform data included in the dump file to produce a waveform display graphically depicting the states of selected IC signals as functions of time.
While a designer thinks of an IC as being a hierarchy of cells and modules, a typical simulator ignores the hierarchical nature of the IC design and models the IC simply by determining the behavior of each individual cell's output signal(s) to that cell's input signal(s). Similarly, while a designer may conceptualize several nets as forming a bus for conveying a sequence of bus transactions during a simulation, the circuit simulator determines only the behavior or each individual signal of the IC as a function of time and ignores the fact that a signal may conceptually form a part of a bus. Thus while the designer may think of some sets of signals as being buses and may think of various patterns of signals conveyed on those buses as being bus transactions, the simulator is only concerned with whether each individual signal is high or low at any given time. When a simulator creates a dump file during a simulation, the dump file may include waveform data representing the behavior of each individual signal of a bus, but will typically say nothing about the bus that the signals form and will provide no information regarding any transactions occurring on the bus. Though waveform display software can produce a waveform display depicting behavior of all of the signals forming a bus, the relationship between the states of those signals at any given time and the transaction they may represent will not always be readily apparent to the designer.
Nonetheless, when a designer wants to know whether the high-level modules that communicate though a bus behaved correctly during a simulation, the designer may want to know which bus transactions occurred on that bus and when they occurred during the simulation. The designer may be able to deduce the transactions carried out over a bus from the waveform display of the signals carried by the bus, but that can be a daunting task, particularly for large buses having complicated transaction protocols.
For example, devices forming components of a system-on-chip (SoC) within some ICs communicate with one another through buses conforming to an advance microcontroller bus architecture (AMBA) specification. An AMBA bus system includes two buses; a high-speed system bus for interconnecting embedded processors to high-performance peripherals, DMA controllers, on-chip memory and interfaces, and a peripheral bus linked to the system bus through a bridge for interconnecting ancillary or general-purpose peripherals. In an advanced high-performance (AHP) version of the high speed AMBA bus a device acting as “bus master” communicates with another device acting as “bus slave” by either writing data to or reading data from bus addresses within the slave. A bus transaction may include a sequence of one or more read or write phases (“bus transfers)” relative to addresses residing within a portion of bus address space the slave occupies. A transaction can span many clock cycles, and since the duration of a given transaction depends partly on the speed with which individual slave devices acknowledge each bus transfer included in the transaction, the number of clock cycles a given transaction consumes can vary. Thus the signal pattern for a given bus transaction can vary depending on how long the master must wait between each bus transfer included in that bus transaction.
Since the AHP bus allows more than one device to act as bus master, the bus system includes an arbiter for resolving the bus masters' competing demands for bus access. To increase the efficiency of bus use, the bus arbitrator can time multiplex transactions initiated by different bus masters thereby interleaving bus transfers associated with transactions initiated by different bus masters. Thus the bus signal pattern produced by a given bus transaction not only varies depending on the speed with which a slave involved in the transaction can process each bus transfer, it also varies with the current level of demand for the bus by competing bus masters. The complexity of the transactions occurring on the AHP bus makes it virtually impossible for a designer to reliably decipher the dump file output of a simulator to determine which transactions occurred on that bus and when they occurred.
What is needed is a system for processing the dump file output of a simulator to determine which transactions occurred on an IC bus and to determine the timing with which each transaction occurred during a simulation of an IC. The system should also produce a display presenting relevant information about each transaction in an easily understood manner.